home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-20 / tn210.zip / TN210.EXE / TN210_10.DOC < prev    next >
Text File  |  1992-07-02  |  9KB  |  159 lines
  1.                                TN210_10.DOC
  2.                          SYSOP COMMAND LIST PT II
  3.                        ****************************
  4.  
  5.     LOCKING  ROUTES -- There may be times a NodeOp will want to modify the path
  6. quality  value  of a route to a given node.  If  for network management reasons
  7. one wants to isolate one  network from another as  far  as  preventing the flow
  8. of  NODES  broadcasts  from  intermingling,  the  locked  routes  technique  is
  9. preferable over the locked nodes procedure.   If one wants the existence of the
  10. isolated  node  to  be known,  then a combination  of  nodes and routes locking
  11. could be used.  The locked routes  command is:
  12.  
  13.  
  14. R PORT [LOCKED NODECALLSIGN] + PATHQUALITY
  15.  
  16.     To unlock the routes use:
  17.  
  18. R PORT [LOCKED NODECALLSIGN]  - PATHQUALITY
  19.  
  20.     The  process  of  locking  routes or nodes as  explained  here   is  called
  21. "perming."   Perming  is normally done when it is necessary to IMPROVE  network
  22. throughput.  The most common example of perming is when reliable neighbor nodes
  23. have their PATH QUALITY values set HIGHER than the value listed in Parameter 2.
  24. The ROUTES locking command is used for this situation.     If the NODES locking
  25. command  were to be used, then  the  neighbor would  remain in the NODES tables
  26. and therefore be broadcast into the network  even if that neighbor should fail.
  27.  
  28. In the  early days of networking,  it was discovered many areas were subject to
  29. short periods of enhanced VHF propagation.   When this occurred,  distant nodes
  30. would suddenly be heard by local nodes.     The  dynamic  routing  mechanism of
  31. TheNet  would be tricked into thinking these were new local nodes and broadcast
  32. their existence accordingly.   A short while later when  conditions returned to
  33. normal the network would be confused.   It would take  several  hours  for  the
  34. original routing to be restored.   During this period, users would for the most
  35. part be unsuccessful in connecting to distant nodes since the "correct" path no
  36. longer existed.
  37.  
  38. Different  solutions to  this problem were proposed.   The technique originally
  39. publicized in 1988 by Doug Everitt, N5DUB (then editor of The NODE) began to be
  40. universally adopted.  Doug recommended the radio path quality parameter be  set
  41. at a value lower than the standard  "192"  typically seen  for VHF radio paths.
  42. He  recommended values for parameter 2 be in the range of 40 - 80.   The NodeOp
  43. would then determine who his reliable neighbors were.    The neighbors are then
  44. locked  to a "standard value" of "192"  by use  of  the  SYSOP  ROUTES  locking
  45. command.
  46.  
  47. Known as "Reliable Neighbors" routing,  this technique solved network confusion
  48. brought on  by periods  of temporarily  enhanced propagation.    Here is how it
  49. works.    New nodes seen as  neighbors are  automatically assigned a radio path
  50. quality  value  below the broadcast parameter cut-off value.    Since the newly
  51. propagated  node is  not  rebroadcast  into  the  network,  circuit reliability
  52. remains undisturbed.  While application of this technique applies mainly to VHF
  53. simplex  networks,  under some   circumstances it also  may be used with  half,
  54. full-duplex and, isolated LAN nodes.
  55.  
  56. A reliable neighbor routing
  57. table may look like this:                        SYSOP action:
  58.  
  59. SONORA:XE2FE-1} Routes:
  60.   0 BISBEE:WA7KYT-1 192 24!                      R 0 WA7KYT-1 + 192
  61.   0 NOG:KA7TXS-2 192 16!                         R 0 KA7TXS-2 + 192
  62.   0 LMN:AK7Z-1 192 34!                           R 0 AK7Z-1 + 192
  63.   0 NOGAL:XE2SOC-5 192 5!                        R 0 XE2SOC-5 + 192
  64.   0 SVA:N7OO-1 100 1
  65.  
  66. Although  not a propagation node,  SVA is automatically  defaulted to the "100"
  67. set in Parameter 2 because the path to it is better via BISBEE.    The reliable
  68. neighbors  of BISBEE,  NOG,  LMN  and NOGAL are permed to "192" as shown by the
  69. exclamation point locking symbol.    A by-product of this technique is it gives
  70. users  assurance  the nodes with exclamation  points and  showing  destinations
  71. greater  than  "0"  are solid routes.   The node  default value  of parameter 2
  72. should be the same throughout the system.  The exact value can be determined by
  73. observation  of the greatest number of hops a distant  node propagates in  as a
  74. neighbor.   The default in the  SET210  utility is "100" which is a  reasonable
  75. starting value.
  76.  
  77.     Here is an example of a LOCKED ROUTE for a neighbor that has failed:
  78.  
  79. SVA5:N7OO-2} Routes:
  80.   1 AZ:N7OO-3 245 7
  81.   1 AZSE:N7OO-10 245 18
  82.   1 CONF:N7OO-5 245 1
  83.   1 SVA:N7OO-1 245 19
  84.   1 SVALAN:N7OO-4 245 8
  85.   1 #SVA6M:N7OO-6 245 4
  86.   0 N7DZH-5 192 0 !
  87.  
  88.     In  this  example, HELIO has suffered a power failure and failed.   After a
  89. period  of time  as determined  by the combination  of SVA5's  NODES  broadcast
  90. interval,  parameter 6,  and Obsolescence counter,  parameter 4,  knowledge  of
  91. HELIO  will  ordinarily  go away.  However in this case, HELIO:N7DZH-5 has been
  92. permed  into SVA5's  ROUTES  as a reliable neighbor.   This can be readily seen
  93. by  observing the path quality  value has been fixed at 192 as evidenced by the
  94. exclamation  point  symbol.   By noting the  "0"  in the "number of destination
  95. routes"  column,  we  know  this  is  a  useless  route.   If  and  when  HELIO
  96. comes  back, it's  "destination routes column"  will  show a value greater than
  97. "0."
  98.  
  99.     The  HELIO node has not been  permed into the routes table of SVA5 with the
  100. node locking  command and  thus will not be propagated  during  node broadcasts
  101. until  it  comes  back  on the air again.     With TNPlus, the alias HELIO will
  102. remain  on  SVA5's routes  list until decremented out of the routes table.   At
  103. this  time  it  automatically reverts to the node call-sign,  N7DZH-5 as in the
  104. example above.
  105.  
  106.  
  107.     ADDITIONAL LOCKING COMMANDS  -   With the  introduction  of  version  2.08,
  108. greater network management and node security  has been  added  with the new R 2
  109. and R 3 locking commands.  These commands apply to both user or node callsigns.
  110. In  the  past,  networks had little  protection from those that would introduce
  111. unwanted nodes into the system.   Neither was there recourse, short of shutting
  112. down the node, of preventing unwanted users from accessing the system.  The R 2
  113. and R 3 locking commands are designed to alleviate this situation.  R 2 locking
  114. works with a specific callsign, or callsign + SSID.   Format is the same as the
  115. R 0 and R 1 locking commands, but in this case:  R 2 CALLSIGN SSID + 0.
  116.  
  117.    Examples for SPECIFIC node/user callsigns:
  118.  
  119. To lock:   R 2 W1XXX + 0  or, R 2 W1XXX-5 + 0.
  120. To unlock: R 2 W1XXX - 0  or, R 2 W1XXX-5 - 0
  121.  
  122. An  R 2  application might be to  filter  out a certain SSID from a server with
  123. multiple SSID's.   This would block the  designated callsign - SSID,  but allow
  124. the same callsign with dissimilar  SSID's to pass.
  125.  
  126. The R 3 locking command controls a designated callsign plus ALL SSID's.
  127.  
  128.    An example:
  129.  
  130. To lock W1XXX-5 and all SSID combinations:    R 3 W1XXX + 0
  131. To unlock W1XXX-5 and all SSID combinations:  R 3 W1XXX - 0
  132.  
  133. When locked,  W1XXX is  barred from connecting TO the node,  regardless whether
  134. or not ANY SSID is used.   Callsigns  designated in either of  R 2 or R 3 locks
  135. will not appear in the node's Heard or ROUTES listings.  Attempts to connect to
  136. a locked callsign by a user from the node will be ignored.  In the case where a
  137. node is locked,  if presently in the routes table, it will  remain  connectable
  138. until  decremented to  "0"  by the Obsolescence Count Initializer, parameter 4.
  139. Should a CONNECTED  user be locked,  the lock will not be effective until after
  140. he is disconnected.  Attempts by the user to reconnect will be ignored.
  141.  
  142. The  R 2  and  R 3   locking commands  are also  effective  on certain types of
  143. aliases, some of which depends whether the Callsign Validation Parameter is set
  144. or not.
  145.  
  146.  
  147.     RESET  - This is the big panic button.   When  a PC based node goes berserk
  148. and contaminates  the  network  with "garbage nodes and symbols," one can clean
  149. the node  table  by typing RESET.   This  not  only  wipes the NODES and ROUTES
  150. tables,  it  also  wipes  the  softcoded  INFO section.   Stations connected or
  151. networking through the node at the time of the RESET will be disconnected.   To
  152. use, type "RESET."
  153.  
  154. Within  10 seconds  following  the RESET command,  the node  will broadcast its
  155. existence.   Since knowledge of  previous neighbors and  permed routes has been
  156. lost, this broadcast should not create confusion to the network.    All it does
  157. is introduce itself to it's neighbors.   However, the NodeOp should take prompt
  158. action to restore reliable neighbor routings and INFO messages.
  159.